1. The Field of the Invention
The present invention relates to object serialization. More specifically, the present invention relates to methods, systems, and computer program products to serialize custom user interface objects in custom serialization formats.
2. Background and Related Art
In a broad sense, serialization is the conversion of an object from one representation or format to another. Serialization generally implies a two way process: converting an object from an initial representation to some other representation, and then converting that other representation back to the initial representation. Although at times, converting back to the initial representation may be referred to as deserialization, serialization is a generic term that encompasses both the initial conversion of the initial representation and the subsequent conversion back to the initial representation.
For example, in-memory or live objects may be serialized to persistent or transient objects that are suitable for durable storage or transmission over a network. Currently, it is common practice to use eXtensible Markup Language (XML) as a serialization format for both storage and data transmission. Once stored or transmitted, the XML representation of the object may be serialized (or deserialized) from the XML representation back to an in-memory or live object. The software that performs serialization typically is called a serializer.
Code generation is another example of serialization. FIG. 1 illustrates an example visual user interface designer 100 with an in-memory or live user interface object 110. Visual user interface designer 100 allows a user to define the visual appearance of a user interface object and then generate a source code representation of the user interface object that can be compiled and included within a program. In this example, user interface object 110 is a simple about box, with a title 112 that identifies the object as an about box, window controls 114 for minimizing, maximizing and closing the about box, text 116, and an OK button 118 for dismissing the about box. Typical visual user interface designers generate code similar to the pseudo code that is shown in Table I.
TABLE IClass About : form {label text;Button OK;public About( ) {text = new label( );OK = new Button( );text.location = new Point(0,0);text.text = “. . .”;OK.location = new Point (100, 130);OK.text = “OK”Controls.Add(OK);Controls.Add(Text);}}
The pseudo code in Table I illustrates several problems with conventional serialization within a visual user interface designer. First, conventional serialization within a visual user interface designer typically is limited to a single serialization format, such as code generation. While code generation is certainly a significant purpose for the visual user interface designer, other types of serialization may be desired. For example, an XML representation of the About box may be desirable, perhaps as a universal format that allows user interface objects created in one visual user interface designer to be imported into another visual user interface designer. However, conventional serialization within a visual user interface designer has been tightly coupled with a single format and has not allowed for different serialization formats.
A second problem illustrated by the pseudo code in Table I is that conventional serialization within a visual user interface designer typically produces a new class, like the new About class shown in Table I. For code generation, this is generally the desired behavior because it allows for straightforward interaction with member objects within the new class. However, for many operations, creating a new class when serializing leads to inefficiencies. For example, during much of the design time, only the visual representation of an object is relevant or is most relevant—source code is only necessary when the visual representation is saved to disk. Table It illustrates an equivalent representation for the pseudo code shown in Table I. The difference being that Table I creates a new type, whereas Table II configures an existing type. This second representation may not be useful as finished source code, but can be used within the visual designer as a generic way to persist live object state for features such as undo or copy and paste.
TABLE IIForm About = new form( );label text = new label( );Button OK = new Button( );text.location = new Point(0,0);text.text = “. . .”;OK.location = new Point (100, 130);OK.text = “OK”About.Controls.Add(OK);About.Controls.Add(Text);
A third problem is that conventional serialization within a visual user interface designer generally is limited in how serializers are extended for new types and/or new serialization formats. While it was possible to call a serialization provider for a new type or format, conventional serialization required a metadata attribute to be compiled into a type for the serialization provider to be known. Accordingly, recompilation is required to provide new serialization formats and to serialize new object types that were not preconceived by an object's developer. Aside from being inconvenient, recompilation may not be possible in some circumstances, such as when third party objects are serialized.
Of course, it should be noted that a visual user interface designer is merely one example of software that generates code for a graph of objects. In many circumstances, code generation may be the fastest and most efficient way to recreate a graph of objects. As illustrated above, however, conventional serialization, particularly where code generation is concerned, suffers from various shortcomings that limit its usefulness.